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A NEIGHBORHOOD LOCKING TECHNIQUE FOR 
INCREASING CONCURRENCY AMONG TRANSACTIONS 



FIELD OF INVENTION 
The invention relates to the field of data processing systems. More specifically, the 
invention relates to the locking techniques for management of data in database systems and 
modes of locks acquired on various data items. 

BACKGROUND OF INVENTION 
A database management system (DBMS) supports transactions to access data items 
stored in a database. Before actually accessing the items, a transaction acquires locks on the 
data items that it wishes to access. Typically, a read only or read/write access may be 
requested on the data item. Generally, this is termed as shared and exclusive access in the 
literature. Thus locks are requested in a pair Resource, lock mode>, where the lock mode 
indicates the kind of access the transaction needs on the resource. Typically these modes are 
denoted as S or X lock modes. If a transaction owns an X lock on a given resource, no other 
transaction can own any lock in any mode on that resource. This is generally known as a 
lock conflict. Thus X conflicts with all other modes, and S conflicts with X mode. However, 
S is compatible with another S mode lock on the resource. 

In the interest of performance, often it is useful to define structure on data. For 
example, data in a typical database can be classified into tables and records in a table. An X 
lock on a table can be considered as an X lock on all rows in the table. This technique is 
termed as hierarchical locking. Only using X and S locks are inadequate in supporting 
hierarchical locking, and therefore a typical DBMS supports many more lock modes, to 
enhance transaction concurrency. 

For example, most DBMSs use IS, S, IX, X, SIX and U lock modes for controlling 
concurrent accesses to data items. The IS mode refers to intention shared (obtained on the 
table), intention to take S locks on underlying rows. The IX mode refers to intention 
exclusive (obtained on the table), intention to take X locks on underlying rows. The S mode 
refers to shared, if obtained on the table, implies an S lock on all underlying rows. The SIX 
mode refers to shared intention exclusive, a combination of S and IX, obtained on the table. 
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The U mode refers to update lock (can be obtained on the table), it means that a X lock may 
requested on the data item in the future. 

Typically a database consists of isolated transactions. The degree of isolation may 
vary among transactions. The American National Standards Institute (ANSI) has defined 
5 various degrees of isolation from strict SERIALIZABLE to DIRTY READ. Existing lock 
modes may be sufficient to synchronize data access among serializable transactions. But, the 
lock modes described above are too restrictive in terms of avoidable conflicts as per the 
semantics of non-serializable transactions. 



15 



SUMMARY OF THE INVENTION 
New lock modes are based on the concept of neighborhoods and are applied to spaces 
in indexes. The new lock modes include a Read, or shared, neighborhood (Snei) lock mode 
and a write neighborhood (Xnei) that enhance concurrency among non-serializable 
transactions. 



BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a diagram of a database management system that supports neighborhood 
lock modes. 

FIG. 2 is a schematic diagram showing locking operations in the database 
20 management system. 

FIG. 3 is a schematic diagram showing a neighborhood associated with a tuple. 
FIG. 4 is a schematic diagram showing how a write operation inserts a tuple into the 
neighborhood. 

FIG. 5 is a schematic diagram showing how two transactions operate concurrently 
25 with respect to the neighborhood. 

FIG. 6 is a schematic diagram showing how the two transactions can both operate 
concurrently during an insert operation. 

FIG. 7 is a table showing how neighborhood lock modes operate with respect to other 
lock modes. 

30 FIG. 8 is a schematic diagram showing how a read operation operates concurrently 

with a neighborhood insert operation. 
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DETAILED DESCRIPTION 

FIG. 1 shows a database system that includes database 8 and a processor 4 (Central 
Processing Unit (CPU) and memory) that stores and executes software for a Database 
Management System (DBMS) 6 and a lock manager 10. A computing device 2 containing 
processor 4 in one example is a server. The processor 4 may be a single CPU or multiple 
CPUs that operate in the server 2. The database 8 is typically stored on a plurality of Direct 
Access Storage Devices (DASDs) although only one such device is illustrated in FIG. 1. The 
DASDs may be, for example, disk packs, and it will be understood by those skilled in the art 
that the database system includes the required DASD controllers and channels that establish 
the communication between the database 8 and the processor 4. In another example the 
database (8) may be stored inside the main memory (4) itself. 

Terminals 1 are any Input/Output (I/O) device that accepts requests from and 
returning results to users. For example, the terminals may be Personal Computers (PCs) or 
applications that use the advertised application programmer interface (API). Transactions 
and queries are submitted from the terminals 1 and are processed concurrently by the DBMS 
6. 

A Lock Manager (LM) 10 is a module of the DBMS 6 that helps the transactions in 
acquiring and releasing the locks on data items in the database 8 in a controlled manner. The 
LM 10 needs to make sure that conflicting accesses to a given data item are not granted 
simultaneously. For example, if a simultaneous read and write access has been granted on a 
data item, then the reader of that data item may see an incomprehensible state of the data 
item. Thus some lock requests may not be granted to different transactions simultaneously, 
since there can be conflicts in the lock grant requests. 

All transactions request that locks be granted in a desired lock mode. For example, 
the reader may request a lock in S mode and a writer may request the same lock in X mode. 
If S and X are defined not be compatible, then the LM 10 guarantees that no writer has access 
permission. In other words, no X lock exists on the data item if a S lock has already been 
obtained on that data item. Thus a reader can read a consistent state of the data item after S 
lock has been obtained on that data item. The LM 10 uses these and other conventional lock 
modes along with new neighborhood based lock modes described below. 

Referring to FIG. 2, the triangle represents a tree index 12. A range of values in the 
index 12 is locked by always ensuring that the next tuple via the index 12 is locked at the end 
of select, insert and delete operations. Consider an example of the usage of the 
aforementioned lock modes in the case of an insert operation 14 and a read operation 17, both 
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executing under a non-serializable isolation mode. Additionally, assume that the read 
operation 17 uses the tree index 12. A.so assume that the DBMS 6 (FIG. 1) is designed to 
support serializable scans when using the tree index 12. 

The items A and C represent tuples in a table 16, on which the index 12 is defined. 
Assume that the read operation 17 has already visited A and C. The insert operation 14 needs 
to insert a new tuple B that is positioned in the index 12 between A and C. At thts potnt, 
before allowing the insert operation 14 to insert tuple B in the index 12, the lock manager 10 
must ensure that no serializable scanner (the read operation 17) has looked at the surroundmg 
area that includes tuples A and C. Otherwise the read operation 17 will be non repcatable 
even for serializable transactions . 

Consider mat the read operation 17 holds a lock on tuple C in «S" lockmode. A, thts 
point the insert operation 14 needs to lock what will be the tuple next to tuple B in the index 
,2 ie tuple C. The insert operation 14 checks if a read operation under serializable tsolabon 
has read tuple C or not. If the insert operation 14 can request an X lock on tuple C, for 
instant duration, inserts in the same area could be concurrent. But as can will be seen from 
the compatibility matrix in FIG. 7, the lock manager .0 with not allow the insert operatton 14 
t0 ,ock on tuple C in mode "X" until the -ST lock on tuple C is released by read operatton 17. 

New lock modes Snei and Xnei are recognized by the lock manager 10 and allow the 
insert operation 14 to succeed when there is no serializable reader in the vicinity. The Sne, 
lock mode refers to a read on the neighborhood. The Xnei lock mode refers to wrtte 
permission on the neighborhood. In one embodiment, these two lock modes may be used for 
tuples accessed by non-serializable transactions. Serializable transactions, on the other hand, 
hold these locks implicitly since they hold stronger locks on the tuple. 

For example, the read operation 17 may be a non serializable read operation m the 
mod c Sn, which stands for S-non-serializablc. The insert operation 14 then requests a Xnet 
lock mode through lock manager 10, which is compatible with Sn, and therefore granted. 
Thus the insert operation 14 allowed to succeed by the lock manager 10 even in the presence 
of concurrent non-serializable read operation 17 in the same vicinity. 

Let (V <) be a totally ordered set. Let v be an element of V. By the left neighborhood 
j of v in V we mean the subset {V | V < v> of V. Suppose we are given an ordered sequence 
v , Vj v, of elements from V. By the leas, left neighborhood of element v, relative to the 
given ordered sequence we mean the subset (v | v ,, < v < „} of the left neighborhood of v„ 
This set represents the 'gap or space' in the given sequence, that is, all the elements in the set 
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canbe insertedbetweenv.andv,, and no — 
without violating the given ordering. 

efmp.es. AU tup.es can be ordered in domain D in many different ways, ^ada^ae 

native to to^^^****"**???'^ 
corresponding table 15. For example, the neighborhood for tuple G m FIG. 3 are the 

.east left neighborhoods relative to the total orderings defined by the index 12 and the 
pXsical ordering on tab.e 1, The neighborhood oftupleGis defined as the nnronof al. ,ta 

A.upleGanditsneighborhoodlSaretwodifferent.fttought.ghtlyreated.e tme, 

permissionontheneighborhood.8. A transaction may be allowed to read and/or write the 

neigbborhoodl8oftup.eG.even when it has no access permission, «^«* tt 
Referri„g.oFIG.4,awriteoperation24ontheneighborhood.8sph,sthe 

Cevenlocx modes: IS, S, FX, X SIX, U, Sn, Xn, U„, Xnei and Snei. TTte Sn, Xn and Un 
^cKmodesareVhecounterpartsofS.XandU.butareonlyusedhynon-senahzhle 

these lock modes are described below. 

Referring to FIG. 5, suppose a transaction T holds a lock on a data item d. What 
^sactionTcan do with da. item d and/or its neighborhood 30 (if d is a tuple) ,s explamed 
Zl.aiscussedbelowiswhatanotherftansacftonTcanorcannotdow.^daUt.m 

d and/or its associated neighborhood 30. Data items contained in a course granu.e are 
referred to as ingredients. 
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S - Shared: —ion T locks data item d and the neighborhood 30 in shared mod. 
Any transactions changing data itemdor the neighborhood 30 are prohibited. T— T 

modify the data neighborhood. A second transaction T can read data 

ingredients. Transaction T camro, write data item d or its ingredients, nor mod.fy the data 

"'^T-Tnrntion shared: Transaction T is planning to read some lower level dam item 

(ro w)ofthe table 32. Transaction T cannot read the lower.eve. portion of table 32 antd .« 

obtains a lock on the related data item d. 

X-Exc,nsive:Transactio„T,oclcsda,aitemdand,heneighborhood30 1 »e X clu,,ve 

m0 de NoothertransaetionsareallowedtobeactiveondataitemdortheneighborhoodJO, 
noteveninSneimode. Transaction T can read and write data item d and its ingredients. 
Transactions alsomodify die neighborhood 30. Transaction T cannot read or write data 
item dori«singredien K; n O rmodifythedataneighborhood30. 

IX - intention exclusive: Transaction T is planning to write some lower level data 
item (row) of the table 32. Transaction T cannot read or write any row in the table 32 until 
proper locks are obtained on the row. 

SIX - Shared intention exclusive: Transaction T requests this lock mode on table 32 
when transaction T needs to read many rows on tabie 32 but write only a few rows 
20 TransactionTcanreadrowsof.ab,e32,huti,canno,writeanyrowoftable32w,thouta 

' OCkS ' U - Update: A transaction that reads a data item but expects to write the same data 
25 d ecidesnottowitetheda,a.Thismodehe,psinavoidingdead,oc k s,nco»ve«mg tockto 
Xlocks. TransactionTcanread.bntnotwrite.dandiUing.edientsandcannotmodifythe 
neighborhood 30 if data item d is a tuple. Transaction T cannot oh^n a new rea^wnte 
perlission for data item d or its ingredients. However, transaction T can read data item d 

30 ingredients, nor modify the neighborhood 30. 

Referring to FIG. 6, the following modes are used to promote a higher level of 
concurrency for non-serializab.e isolation levels, especially for scanning tables: physical, 
nash oratree index. These modes are valid for locking tuples. In FIG. 6, data items A and 
C represent pointers in an index 40 that point to associated tuples A and C, respectively. 
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,„,„„„»— 2 T»«»I..T— —»-""•"— 
neighborhood 42. , ( ea(J or 

X„ei - Weak Exelusive neighborhood look: Transaction T does wa 

x ,„nTloeks the neighborhood 42 for shrinking by insertmg anew 
write tnple C. Transact™ T looks the ne g neighborh ood 
tuple B. Transaction T cannot reador write ^ ^ ^ neighborhood 42. 

/io Tmmaction T 1 can read and vmte tuple diiu 

42. Transaction ^ ^ transactlon T 

5 Note that transaction V cannot have an X lock on tuple 

"t on Transaction! does not have interest in the tuple neighborhood 42. 

taction T can read tnple C if it has already got permrsa.cn to do so, 
lu p,eC TransactionTeanaisomod i fy,hetupleneighborhood42. 
tuples, "a „ Jwk . This operation is an tndication that 

Snei- Weak Shared neighborhood lock. Inis opera 

Snei wea^ The lock acts as a sentry for transaction 

A lock compatibility matrix is shown in FIG. 7 tor some 
„ h d above Each row defines what happens when a new lock request is made on the 

. r:r: ^^«^-^«-^zr: 

th emode,nd,eatedbytheco,nmns. T= — 

currently held on the given resource. In one example, 

7 Attorney Docket No. 3222-4 

PATENT APPLICATION 



20 



10 



15 



r 2 (FIG n The lock manager 10 (FIG. 1) is operated by 
seriaHzab.e.teni.^hCdaSn.ocUontupeC. An ,n 2requestsand 

O„fteo«herhand,ifthe re adope ra t,on50,saser,al 

— -2 :::r=r 

row C is next «o row D in a non-unique index, ofi, ^ 
XiocxonrowBandaX^o^p.pnetarywea^^ 

at least a W lock in IBM s DB2), on row fa ^ c 

takes a xw lock on row C, which is compatible and an Xne, 

for an index based read operatton. For a table scan, 

req uested on a fictitious end of table tuple. ^ ^ 
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and detail without departing from such prmctples. Churns are 
variation coming within the spirit and scope of the Mowing ciarm, 
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